Subject: DLSw minutes, Feb AIW

From: [email-masked]
Date: Sun, 17 Apr 94 16:47:31 PDT

Data Link Switching Related Interest Group
Meeting Minutes

APPN Implementer s Workshop
February 1994   Anaheim, CA

1.     Opening

     a.  Agenda.  
Louise Herndon Wells proposed an agenda which included 
approval of RIG technical plan and procedures followed 
by a discussion period for each RIGlet.
**CONSENSUS**  Approved proposed agenda without debate.

     b.  RIG Designation.  
Louise Herndon Wells presented new DLSw group 
designation that we requested last meeting:  Related 
Interest Group (RIG) and discussed proposed AIW RIG 
procedures.  No discussion.  
**CONSENSUS** Accepted change to RIG status.

     c.  Technical Plan.
Louise Herndon Wells presented proposed DLSw RIG 
technical plan, which had been posted to the network.  
Peter Gayek (IBM) noted that different RIGlets
are at varying stages in the development of their
proposals so we are unlikely to reach Approved
Direction status for every proposal in this meeting.

**CONSENSUS**  Adopt proposed Technical Plan as proposed 
with three changes:  
1.     SNA and NetBIOS (eliminate specific reference to 
APPN); 
3.d.  Third 1994 AIW is in October (not September); and 
4.     ...submit to IETF as a proposed (not draft) 
standard.

     d.  Procedures.
Louise Herndon Wells presented proposed DLSw RIG 
procedures which had been posted to the network.
Louise pointed out an implication of the RIG rules that 
only formal AIW members can submit proposals to the RIG.  
Non-members may subscribe to the mailer and comment on 
proposals but may not submit proposals.
Louise lead discussion on the topic of RIG meetings held
separately from AIW meetings.  These are permitted under 
4c of the Draft Procedures and should be arranged by e-
mail.
If a RIGlet proposes any such meeting but a member
of that RIGlet is unable to attend and voices a 
significant objection to this meeting on the e-mail, an 
official 'meeting' cannot occur.  There was no 
discussion on how such a 'veto'should be decided on the 
mailer, i.e., what constitutes a 'significant
objection.'
**CONSENSUS**  Adopt proposed Procedures as proposed.

     e.  RFC 1434 and Patents  
Peter Gayek presented a statement from IBM
regarding RFC 1434 and patents.   One of IBM s patent 
attorney s at Raleigh has advised me that a study of the 
IBM patent portfolio did not reveal any patents having 
claims that would be infringed by implementation of the 
protocols as described in RFC 1434.    No discussion.

     f.  IETF Plans
There followed a discussion on whether/when to take
the output from our RIG to the IETF in order to produce
an IETF standard or to post an information-only
RFC at the end of the RIG process.
**CONSENSUS**  Louise Herndon Wells (ITI), Wayne Clark 
(Cisco) and Peter Gayek (IBM) plus any other interested 
parties to meet at the first break to quickly put 
together a proposal for discussion by the whole group 
after that break.

2.     Proteon Presentation
     Bob Koch and Ed Stern of Proteon presented their 
experience with developing DLSw based on RFC 1434.  
Their product is currently in testing at several sites.  
They discussed positive and negative points.  Their 
suggestions included:  Add all possible pairs to the 
state machine; take DLSw circuits down if TCP goes down; 
find a way to guarantee fairness between sessions; need 
way for DLSw s to find each other (without a big 
database of IP addresses); add discussion of dealing 
with the many types of SDLC; couldn t do SDLC to SDLC; 
proposed ideas for prioritization; need generic DLSw MIB 
(too specific to 6611); solve adaptive pacing problem; 
enter/exit busy has known problems.

3.     Connect/Disconnect - Steve Klein

     a.  Agenda.
          1. Updated RFC 1434 FSMs - Which to 
include? (has not heard objections; researching 
questions)
          2. Proposals  for handling circuit-setup 
collisions 
          3. Proposal for separating topology 
establishment from circuit establishment

     b.  Updated RFC 1434 FSMs
     Comment received:  they didn t add much.  True, but 
they conform with 6611 and with field experience.  They 
are not incompatible with previous versions, but provide 
more information.    5 categories of issues:     
     1)  Separating explorer and circuit setup - any 
changes to FSMs?
     2)  State change questions
     3)  Old or new?  Newer FSMs seem more LLC oriented 
  need for generic
     4)  Resolve FSM - Is enter/exit busy in base?  If 
yes, note changes to FSM
     5)  Specification unclear what signals come from 
DLC to FSM

     c.  Separating explorer and circuit setup
     Debate:  Data-link independent (make SSP generic) 
OR support LLC2 & SDLC.  Operate at MAC and SAP between 
routers.  DLCs can connect separately.  But secondary 
and configuration SDLC can t work this way.  Keep 
existing signals and include example DLC-specific uses.
     
*     ACTION ITEM:  Alan Bartky will post sample flows 
for SDLC within one month.
*     ACTION ITEM:  Steve Klein will post scenarios from 
Gene Cox.
*     ACTION ITEM:  All will post by March 11 any 
 footnotes  to tables, noting they are optional.
*     ACTION ITEM:  By March 4, all will post comments 
to 
Steve Klein s proposal on separating explorer/circuit 
setup.

     d.  Circuit collisions
     Three proposals received with three different 
approaches
     Don t want dependency on TCP/IP (in 2 proposals)
     MAC address on Bernie s proposal - send back 
outstanding CANUREACH
or new guy always loses (e.g., old guy doesn t 
understand capabilities exchange).
*     ACTION ITEM:  3 weeks to consensus on network.  (2 
week warning)

     e.  Command/response bit
     QLLC carries distinction between command and 
response.  But is a local connection.  XID 
command/response does not currently have a meaning.
*     ACTION ITEM:  by March 18 Jim Cobban will post 
proposal.

     f.  SDLC - Did not discuss - ran out of time.  Will 
solicit proposals.
     
4.     Flow Control - Shannon Nix

     a.  Agenda:  1) Where were we?, 2) Discuss 
proposal, 3) List issues, 4) Discuss issues, 5) Identify 
action items

     b.  Where were we?
**CONSENSUS** from last meeting: 1)  FC needed at a 
circuit level, 2) Some FC needed at transport level, 3) 
scope of work restricted to external FC protocols, 4) 
Adaptive pacing as an option.   
Issues open at end of last meeting:  1) Base FC 
mechanism, 2) Transport connection model, 3) Adaptive 
pacing patent

     c.  FC Proposal Highlights
1) Adaptive session-level pacing available only through 
APPN patent license, 2) Four levels of FC support (None, 
ON/OFF, Fixed, Adaptive (not APPN mechanism)), 3) 
Capabilities exchange, 4) Circuit level only, 5) 
Receiver-controlled, 6) Reset window option.

     d.  Issues
1) Tranport level FC?  2) Too many FC levels?  3)  
Identify base FC level, 4) Reset window to one or zero?, 
5) No turn-around cycle feedback, 6) Definition of MIB 
variables, 7) Prototyping?, 8) Separate initial window 
sizes for fixed and adaptive.

     e.  Discussion

          1.  FC levels:  too many levels.  
**CONSENSUS**   Only adaptive pacing

          2.  Reset window to 1 or 0?  
**CONSENSUS**  reset to 0 - eliminates a control vector 
and one of the pacing windows.

          3.  No turn-around cycle feedback:  Gayek 
suggested keep as proposal, must be sent on 1st request.  
Must sender be able to override request to increment? - 
not decided.  Explore on net Paul s idea about sender 
input.  
*      Action Item:  Paul will post within one month (by 
March 14).

          4.  MIB variables - more?   Minimal 
discussion.  Willl get feedback.

          5.  Prototyping  Requested feedback from real-
life implementations
*     ACTION ITEM:  All implementers requested to post 
feedback

     f.  Flow control action items
*     Peter Gayek, IBM, to revise proposal per 
following:
          1.  Base (only) option is adaptive pacing
          2.  RWI resets window to zero
*     Paul Wood, Metaplex, to develop proposal(s) on 
sender feedback on ability to use window size
*     From all participants:  Input on MIB variables
*     From all participants:  Input on 
implementation/prototype experience

5.     SIG and New RIG Designation -Louise Herndon Wells

     Louise explained again how the new RIG designation 
was exactly what we had asked IBM for to appropriately 
reflectour relationship with the AIW that is different 
from SIGs.

6.     Relationship of DLSw and MPTN - Rick McGee

     a.     Rick McGee, IBM, addressed appropriate 
contexts for MPTN and DLSw.  DLSw works better in a 
router-centric network.  For application-on-SNA to 
communicate to another application-on-SNA,when there is 
a TCP/IP network between them.

     b.     MPTN has two modes.  The first is 
application-based, allowing users on systems with 
differing protocol stacks to access applications on 
systems with other protocol stacks.  For CPI-C 
application-on-TCP/IP to access CPI-C application-on-SNA 
or for sockets-application-on-TCP/IP to access sockets-
application-on-SNA. 
     The second MPTN mode is as a gateway node between 
two different protocol environments.  Here, the MPTN is 
a layer-4 gateway.

7.     IETF Standards Process
     We discussed the benefits, risks, and costs of 
taking our DLSw standard to the IETF as well as timing 
considerations.  After considerable discussion, we 
reached the following agreements.

**CONSENSUS**  We intend to propose our completed AIW 
DLSw standard to the IETF to be also accepted as an 
Internet standard.  

**CONSENSUS**  To shorten the time between our 
completion and the IETF completion, we will request a 
BOF session at the March IETF.  Because attendance at 
the BOF is one of the criteria used by the IETF to 
determine whether to approve a working group, we request 
that as many DLSw participant companies as possible send 
a representative to this BOF. 
 
**CONSENSUS**  The AIW is the standard development 
body for the DLSw standard.  An IETF standard is being 
pursued as an additional industry benefit.  The standard 
developed by the AIW DLSw RIG is the document submitted 
to the IETF for its approval.  The DLSw RIG AIW meetings 
are, simultaneously, the IETF working group meetings.  
These meetings are open to all interested parties.  The 
AIW DLSw mail exploder is, simultaneously, the IETF 
electronic mail forum.  Participation in the mail 
exploder is open to all interested parties.  The AIW 
DLSw RIG is the only group authorized to change the 
document.  This is similar to the relationship between 
the ATM Forum and the IETF, and between the Frame Relay 
Forum and the IETF.  The only change we are aware that 
this will create in the AIW standard development process 
is that IETF members as well as AIW members would be 
able to make submissions for DLSw.

**CONSENSUS**  The AIW DLSw RIG chair, Louise Herndon 
Wells, will also be the IETF DLSw working group chair.  
The AIW DLSw RIG editor, Alan Bartky, will also be the 
IETF DLSw working group editor.  Shannon Nix was 
selected as the DLSw vice-chair and will manage the DLSw 
process at the IETF meetings that Louise Herndon Wells 
is unable to attend.  At the full IETF meetings, a 
subset of AIW DLSw RIG participants will manage the IETF 
standard process, propose the AIW DLSw RIG documents, 
and bring back to the DLSw mail exploder or next AIW 
meeting any feedback from the IETF organization.

8.     Capabilities - Wayne Clark

     a.     Agenda   Review of AIW #3 consensus items, 
Review capabilities exchange format proposal, Discuss 
capabilities exchange protocol issues, TCP connection 
proposal, Summary and identify next steps

     b.     Review of AIW #3 consensus items
       1)  Shall DLSw be broken up into a base set + 
option sets? Yes
       2)  What feature comprise the base set? 
Base = RFC 1434 - NetBIOS (optional) + base MIB + 
D(Flow Control SIGlet) + D(Connect SIGlet)
       3)  What features comprise the option sets?  
NetBIOS, Loop Prevention, Priority/COS, Advanced Flow 
Control, MAC Address list (at CANUREACH time)
       4)  Should a vendor ID be included in the 
capabilities exchange?  Yes
       5)  Should the capabilities exchange be carried 
over TCP or UDP?  TCP
       6)  Is it desireable to have a directory server / 
name server?  Minimal one - see MAC address list
       7)  Should CANUREACH / ICANREACH be optional?  
n/a
       8)  Format of the capabilities exchange?  
Generalized data stream (GDS) variables with structured 
subfields

     c.     Review capabilities exchange format 
proposal:  
          (The following is a summary of Wayne Clark's 
posted proposal.)

--------------------------------------------------------
| LL | ID=F000 | Capabilities Exchange Control Vectors |
--------------------------------------------------------

0-1     Length of GDS variable
2-3     GDS ID: X'F000'
4-n     Control vectors

Capabilities Exchange Control Vectors include
o     5 bytes for vendor ID (X'81')
o     n bytes for version string (X'82')
o     3 bytes for NetBIOS support (X'83')
o     3 bytes for Loop Prevention (X'84')
o     4 bytes for Flow Control Support (X'85')
o     4 bytes for Initial Pacing Window (IPW) (X'86')
o     8 bytes for MAC address masks (X'87')
o     8 bytes for MAC address value (X'88')
o     Sets of n bytes for MAC address lists (X'89')

Changes at meeting:
     Eliminated flow control support vector
     Combined MAC address mask and MAC address value
     Added 8A for NetBIOS name - needs padding rule, 
stars
     Added 8B exclusivity in MAC/NetBIOS list
     Only vendor ID and initial pacing window are 
required; others are optional
     
     d.  Format-related issues

       1)  GDS variables:
            - ID(s) to be assigned by the Architecture 
Reference SIG after we reach AP status
            - We need to decide on what comprises a GDS 
variable (below) to determine the number of variables we 
need
            - GDS variable patent is not an issue since 
DLSw won't use the continuation bit

       2)  Control vectors
           - IDs can be assigned by DLSw alone
           - Use the range X'80' - X'FF' since the 
control vectors are tied to a particular GDS variable
           - Do we want a DLSw-specified range and a 
vendor-unique range?  Decided NO, have a vendor control 
vector.
           - Should the "L" be inclusive for type LT 
control vectors?  Yes
           - Do we want to use multiple-instance control 
vectors (for example, with the MAC address list CV)?  
Yes (see above)

       3)  Switch-to-switch protocol (SSP) message 
details
           - We need an SSP message type assigned for 
capabilities exchange.  In the interim, will use 'x20'
           - Should we use long or short SSP message 
headers?  Short.  All FF for unused fields

       4)  Specific control vector issues
           - Should version string CV be required?  
Allowed, not required
           - Should a vendor-unique data DV be required?  
Optional
           - Dow we want a supported SAP list CV?  Wait 
for FSM contributions / changes from Connect RIGlet
           - Do we want a NetBIOS name CV similar to the 
MAC address list CV?  Yes.  Contribution from Gene Cox, 
IBM.
           - Do we want both a MAC address list and (MAC 
Address Mask CV and MAC Address Value CV)?  Yes
           - General concern taken into account on these 
issues:  how much to specify to increase 
interoperability versus how much room to leave to 
innovate, compete, and adapt to specific markets

       5)  Single versus multiple GDS variables
           - Various options exist (single GDS variable 
with individual variables in CVs, multiple GDS variables 
with individual variables in CVs logically grouped 
together, multiple GDS variables with no CVs, a 
variation of single GDS variable with multiple-instance 
CVs)   Selected Single GDS variable with multiple 
instance subvectors
           - Possible limitations for long lists of MAC 
addresses and/or NetBIOS names

       6)  Capabilities exchange format errors
           - Malformed GDS Variable:  Invalid GDS 
length--not in the range of (4 + length of required CVs) 
to length of message, Invalid GDS ID, Length of CVs 
doesn't match length of GDS variable.
           - Invalid control vector ID
           - Malformed control vectors: length doesn't 
match CV requirements, invalid value in CV data
           - Duplicate CVs (for non-repeating CVs)
           - Out-of-sequence CVs (if multiple-instance 
CVs allowed)
     
       (The next six issues are protocol-related issues)

       7)  Lack of a capabilities exchange?  indicates 
back rev DLSw

       8)  What other conditions indicate a back rev?  
Receiving a non-capabilities exchanges SSP message

       9)  How long does a DLSw wait for a capabilties 
exchange before declaring it back rev?

     10)  When should capabilities be exchanged -- only 
at start-up or during run-time?  

     11)  What are the required CVs?  Vendor ID, Version 
string

     12)  What happesn when a capabilities exchange 
error is detected? (options include:  Log the error 
locally and drop the connection; Remote sense code an 
dleave connection up; Remote sense code and drop the 
connection)  

     13)  Organizationally-unique identifiers:  Current 
assignment contained in RFC 1340 (reference section 
titled "Ethernet Vendor Address Components").  If your 
organization does not have an OUI, contact Joyce K. 
Reynolds, Internet Assigned Numbers Authority, USC / 
Information Sciences Institute, 4676 Admiralty Way, 
Marina Del Rey, CA  90292-6695,  (213) 822-1511, 
[email-masked]

9.     Loop Prevention - Choon Lee

     a.     Three methods had been discussed on 
electronic mail to discuss.  Only one submission was 
made, using a modified TEST packet.

     b.     Choon Lee presented his proposal for 
handling loop prevention.  Several concerns were noted 
with proposal, including concerns with timers and 
delays.  

     c.     It was agreed to solicit another proposal 
that would not have these problems.  IBM agreed to look 
for someone internally to generate another proposal.

10.     Priority/COS - Gene Cox

     a.     This RIGlet has significant relationships 
with all the other RIGlets and their work -- 
particularly with capabilities, connect, and 
conformance.  
Coordinator is watching them and working with them to 
identify and address priority/COS issues as they arise 
with their proposals.

     b.     Discussed first proposal.  Several transport 
connections for differring COS levels.

     c.     Discussed second proposal.  Two connections 
-- always send on port 2065; always listen on port 2067

11.     Conformance/Validation/Interoperability - Rick 
Konlon     

     a.     Burt Gearhart of ACT is the new coordinator 
for the conformance RIGlet

     b.     Introduction
Since there has been little to no activity on the 
network in this RIGlet, Rick Konlon reviewed his 
presentation from the last AIW meeting, including the 
areas necessary for future work.
o     Clarify the purpose of the RIGlet
o     Establish philosophies for compliance
o     Determine the deliverable of this RIGlet
o     Identify what needs to be tested
o     Identify testing methods and facilities
o     Produce the deliverables and submit to RIG for 
approval

12.     Network Management - Peter Gayek (for Glenn 
Aikens)

     a.     RIGlet scope.
**CONSENSUS** RIGlet scope includes SNMP and SNA/MS 
management of DLSw, though most discussion has been on 
SNMP.

     b.     SNMP Management
DLSw conformance requires implementing a base DLSw MIB.
If we agree on trap or alert-worthy events, traps will 
be defined also.

     c.     SNA/MS management
All defined SNMP traps will include SNA/MS Alert 
information (per R. Moore 1/94 draft RFC).
IBM does not plan to lead, but will support Generic 
Alert and RUNCMD definition efforts.

     d.     Direction on MIB content.
o     Base to contain:  RIG algorithm-related and common 
implementation variables.
o     Product-specific extensions may be defined by 
vendors who so choose.
o     Base MIB will not duplicate information in the 
SDLC and 802.2 MIBs
o     Base MIB may contain SETs and administrative 
variables

     e.     Draft work schedule.
o     2/21 - 4/15/94    Solicit e-mail input/reactions 
and produce draft MIB/traps
o     4/15 - June AIW     Incorporate MIB/traps into new 
RFC and solicit final concerns
o     June AIW     Adopt base MIB/traps by consensus 
(Reach AP?  Reach AD by e-mail previous to meeting?)